前言
在醫療機構的資訊安全體系中,「誰能看」與「誰看過」是兩道同等重要、不可分割的防禦縱深。
許多醫療院所最嚴重的資安危機,並非來自外部黑客的滲透攻擊,而是源於內部人員的越權存取(Unauthorized Access)與未經授權偷窺(Snooping)——例如公眾人物、政治人物或院內同仁入院時,非照護團隊的醫護人員出於好奇調閱病歷與檢驗報告。
在 Day 14 中,我們實作了粗粒度的 JWT 與角色基礎存取控制(RBAC, Role-Based Access Control)。今天我們將把存取控制推進至臨床等級的細粒度權限校驗(Attribute/Context-Based Access Control, ABAC/CBAC),並引入 HL7 FHIR 中專為合規稽核設計的核心標準——AuditEvent Resource。
我們將在 Node.js (TypeScript) 後端實作一套非同步不可竄改的稽核記錄器(Audit Logger),確保系統每一次敏感資料的讀取、修改與匯出操作,都有完整的法定數位證據存證!
一、從 RBAC 邁向情境感知存取控制(Contextual RBAC)
在一般的商業系統中,只要使用者角色是 NURSE,通常就能存取所有病人清單。但在急性綜合醫院中,這種權限模型存在致命破綻:
-8 樓西側病房的護理師,不應該任意查詢 6 樓加護病房病患的敏感病歷。
-護理師只應對「當前值班指派病房」或「直接照護清單中」的病患擁有讀寫權限。
因此,臨床存取控制必須結合三個維度:
二、認識 FHIR AuditEvent Resource
AuditEvent 遵循 DICOM Audit Trail 與 IHE ATNA(Audit Trail and Node Authentication)標準,專門記錄系統內發生的安全相關事件。
核心要素(W5 Rules):
-When(何時): recorded(事件發生的精確時間戳記,含時區)。
-Who(誰): agent[](觸發操作的醫護人員員編、角色、請求端 IP)。
-What(什麼操作): action(C 建立、R 讀取、U 更新、D 刪除、E 執行)與 type(事件代碼)。
-Where(在哪個端點): source(伺服器識別與網址)。
-Why / On What(涉及哪位病人與資料): entity[](存取的 Patient、Observation 等 Resource Reference)。
-Outcome(結果): outcome(0 成功、4 次要失敗、8 重大失敗、12 安全阻斷)。
三、AuditEvent 資料結構與 JSON 規格實例
以下展示一次「護理師越權嘗試調閱病患敏感體徵,遭到系統 403 阻斷」的標準 AuditEvent 紀錄:
四、實作非同步稽核軌跡留存服務
稽核記錄不得因資料庫忙碌而阻斷主要的臨床 API 響應,因此必須採用非同步管線(Async Pipeline);同時,稽核日誌資料表必須嚴格禁止 UPDATE 與 DELETE(Append-Only),防止特權管理員竄改軌跡。


發送 GET 請求存取 6 樓 ICU 病患體徵清單:
伺服器立即阻斷並回傳(403 Forbidden):
檢視資料庫 audit_events 表:
產出一筆 outcome = '8' 的記錄,完整保存操作者 IP、時間戳記與嘗試跨區行為,符合醫療資安實地查核(HIPAA / ISO 27799)要求!
小結
今天我們完成了智慧醫療平台最後一塊安全基石:
1.超越傳統角色限制,落實了結合病房空間與照護職責的情境存取控制(Contextual RBAC)。
2.完整導入了國際標準 FHIR AuditEvent 規格,掌握 W5 稽核要素與結果代碼。
3.實作了非阻塞式非同步稽核記錄服務與 Append-Only 安全資料表,確保所有合法存取與越權嘗試均具備法律效力的數位存證。
至此,系統的前端動線、後端轉譯與資安防護已全數建構完畢。明天 Day 27 我們將進入系統穩定度驗證:單元測試與整合測試——模擬臨床極端情境、並行高併發寫入與防呆壓力測試!